home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Apr 89 / T0001-68881 & MacApp2.0b5-Apr89 < prev    next >
Encoding:
Text File  |  1989-04-08  |  2.9 KB  |  74 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  BURBECK.S    to ALCABES
  2.  
  3. Item    8993195                         7-April-89        09:12
  4.  
  5. From:   N0658                           ESL, Robert Penland, ASC
  6.  
  7. To:     MACDTS                          Macintosh Developer Technical Supt.
  8.  
  9. cc:     MACAPP.TECH$                    MACAPP Tech
  10.  
  11. Sub:    68881 & MacApp2.0b5 woes
  12.  
  13. Hi Techies,
  14.  
  15. I submitted a question about a week ago that concerned using the 68881 option
  16. when compiling and using MacApp2.0b5 with MPW 3.0 final.  I received the
  17. following response from Keith Rollin at MacDTS:
  18.  
  19.  
  20. {****************************************************}
  21. I've looked into the problems with printing Reals, and I think that I've found
  22. out what is causing it. It seems to be a Pascal bug.
  23.  
  24. I traced through the code that Robert Penland provided, and found that the
  25. values were being calculated and stored correctly. However something happened
  26. between that time and the time they were printed out. Here's what I found:
  27.  
  28. When the method is entered, the handle to the object is stored in A4. When the
  29. time comes to store a value into fStart, the following instructions are
  30. executed:
  31.  
  32.     move.l (A4),A0
  33.     FPMove.S FP0,$000E(A0)
  34.  
  35. This is just fine. However, this is the ONLY time that a pointer to the object
  36. is dereferenced and put into A0!!!
  37.  
  38. The other 2 values (fStop and fLogStart) are generated and stored correctly.
  39. Then the time comes to print out the string. A pointer to 'fStart =' is pushed
  40. onto the stack, and a routine called _W_STR is called. When it comes back, A0
  41. is trashed!!! The object hasn't moved, so no memory compaction occured; it's
  42. just that A0 has changed and no longer points to the object.
  43.  
  44. Changing your lines to read like this will solve the problem:
  45.  
  46.     fStart := ((12500000.0/4096.0)*224.0)/(128.0*1024);
  47.     fStop := ((12500000.0/4096.0)*448.0)/1024.0;
  48.     fLogStart := Log2(((12500000.0/4096.0)*224.0)/(128.0*1024.0));
  49.  
  50.     tStart := fStart; tStop := fStop; tLogStart := fLogStart;
  51.  
  52.     writeln('start = ',tStart,'stop = ',tStop,'logStart = ',tLogStart);
  53.  
  54.  
  55. where tStart, tStop, and tLogStart are locals.
  56. {******************************************************}
  57.  
  58. This looks like a major bug to me.  Does this mean that anytime I use a writeln
  59. in my code that I'm going to trash the reference to my object? The problem with
  60. the real number values doesn't seem to be confined to just writelns, I've
  61. observed some very strange behaviour just while using real object data fields
  62. in calculations.  Also, why does this only seem to manifest itself when I have
  63. the 68881 option on?  It compiles and runs fine in both debug and optimized
  64. mode without the 68881 option on.
  65.  
  66. The speed of my applicaton is greatly enhanced if I can use the 68881, but
  67. right now I can't seem to do that with MacApp 2.0b5.
  68. I guess my real question is this a known compiler problem and if so is
  69. something being done to fix it?
  70.  
  71. Regards
  72. Robert Penland
  73.  
  74.